Two fixes in this release, let s start with the more important one :) The DBus configuration file shipped with pommed now explicitly allows method calls to org.pommed, which is needed with the newer versions of DBus where the default configuration on the system bus has been made more strict to close a security hole. If the pommed clients stopped working for you after a DBus update, replace /etc/dbus-1/system.d/pommed.conf by the dbus-policy.conf file shipped with pommed. Second fix is related to the Apple wireless (Bluetooth) keyboard, which previous versions of pommed would recognize just fine but reject because it exposes a type of events usually indicative of a mouse (and pommed doesn t listen to mouse devices). This is now fixed for this particular keyboard, so pommed will react to the hotkeys on this keyboard too. For the complete list of changes, see the ChangeLog file in the source distribution. Comments at the usual address :)

pommed 1.24 is out; this is a maintenance release addressing the HID changes in the 2.6.28 kernel. HID quirks have been split out into hardware/vendor-specific submodules; consequently the sysfs path for the fnmode parameter changed as it s now handled by the hid_apple module and that needed to be accounted for. No rush if you re running an older kernel :)

David, I m not saying it lightly: the end goal is censorship, no matter how nicely you try to put it. The goal is to discourage people from posting. They call it peer pressure , which is nothing else but the politically correct equivalent expression for intimidation . The end result is censorship. The idea of censoring the mailing lists has actually been mentioned very clearly in the recent discussions on -devel, and I never thought it would go past that, but it s actually happening. By the way, this could actually morph into a shitty karma system that wouldn t let you post past your monthly allowance and credit earned . How s that for you? You refer to those +1/-1 mails; I find them silly, annoying, useless and a waste of bandwidth and CPU time. That used to be called a me too and generally despised and frowned upon. If you actually want to score posts or posters, get a decent MUA and set up its scoring system the way you like. But keep that to yourself. As Aigars told, there are mail to web forum gateways (more like rendering engines for a mail archive, actually) that will present mails to a list in a crappy web forum of some sort that will come with all kind of crap like scoring, karma and whatever. There s an essential difference between web forums and our mailing lists, though: forums of this kind use nicknames all over the place, our mailing lists use real names. There are privacy issues involved, and I m not giving up on that, either. You want to stop flamewars? Stop replying, especially to tell how intolerable it is and other shit. Just let the damn thing die already. Funny how the well-meaning people are feeling harassed on the mailing lists when they, themselves, are harassing people they disagree with. We don t all have the same views, culture etc. We re not all friends, and we probably never will be. Guess what? It s OK! Get over it and work with each other, because that is what we are here for. If you (general) can t get over it, I m afraid this Project is not the appropriate place for you. Imposing a monoculture of politically correct crap is not an answer to the perceived problems .

This proposal leaves me speechless. The replies even more. The sole fact that there are positive replies kills me. I m really starting to think that this Project could do a lot better without some people. Now if you ll excuse me for a sec, I have a urgent need to vomit. Reality check, people. Get back on the ground.

Christian notes, and rightly so, how much this vote sucks, for various reasons. There are too many viable options (as far as releasing Lenny is concerned) and that makes it tricky to vote in a useful way. And Christian got bitten by it: do not vote by ranking all options 1 to 7, or this vote will end up being our most EPIC FAIL to date. With that many options, the votes will end up diluted and who knows what the result will be. For this vote to succeed and be meaningful, it s pretty much required to rank several options equally. That is, and provided it matches your views, ranking the Let s release Lenny and give the finger to the zealots options at the same level. Be careful when voting on this one. IT S A TRAP.

pommed v1.23 is out, with full support for the late 2008 laptops. The LCD backlight inner workings got figured out finally, but there s a catch: the backlight won t react to the settings when running X11 with the proprietary nVidia drivers on the MacBook5,1 and the MacBookAir2,1. It works fine on the MacBookPro5,1 and it works fine on all three machines with the opensource nouveau driver. Switching to the console before setting the backlight and then back to X does work as a workaround. So there s something up with the proprietary nVidia driver, and my uneducated guess is that the MacBook Pro may somehow be exempt from the issue due to its dual GPU config. I ve also switched the nVidia machines to using the generic sysfs backlight driver in pommed. This driver has been there for some time for the PowerPC machines, so now it s part of the generic pommed code. You need the mbp_nvidia_bl driver in your kernel for this to work. Don t panic! If you don t have it, pommed will fall back to the native driver (nv8600mgt) and everything will work just as before. Pommed will tell you if it has to fall back to the native driver, so check your logs if you want to know. This release of pommed needs testing on all nVidia machines: MacBookPro3,1, MacBookPro4,1, MacBookPro5,1, MacBook5,1 and MacBookAir2,1. If anything doesn t work, tell me about it and I ll fix it.

I’ve just released pommed v1.22, which has been collecting improvements and reworks over the past few weeks; this release also adds partial support for the Late 2008 laptops. Partial support means the LCD backlight is not supported yet. The method for controlling the backlight has to be figured out; if you hear of anything, let me know. You’ll need a recent kernel for full support on these machines, which means either a late 2.6.28-rc or possibly an early 2.6.29-rc. It all depends on how fast the patches get applied to mainline. Patches are needed for the keyboard quirks, trackpad support, applesmc support and sound support, as usual. On the improvements front, wmpomme has become event-driven, eliminating the fixed-rate update and associated wakeups and visual ugliness in some configurations; pommed has got some code fixes, though nothing major; gpomme has got a new Japanese translation. Hopefully the next release will bring full Late 2008 support.

Our DPL has spoken to The Register about the developer status proposal and how we’ll handle it after the release of Lenny. Too bad he hasn’t told us anything about it on our mailing-lists yet. Maybe The Register could create a Debian category so we can more easily look for what our DPL says? (If anyone asks, I’m a Reg reader myself)

Over the past four years (since the infamous Vancouver meeting, roughly), it seems it has slowly become an acceptable practice in this project to come up with backroom decisions instead of coming up with ideas and proposals and building a consensus before moving forward. A number of projects and changes have been brought forward this way since then. No need to make a list, I think everybody remembers the flamewars pretty well. Fact is that Vancouver and dunc-tank (only to name those two) have changed the Project in some ways. People resigned, others changed their level of involvement, but more than anything else, there’s been a split in the Developer body. Something broke at some point, and the spirit just isn’t there anymore. So, we’ll never recover to a state comparable to what Debian was before Vancouver. When you thought things were bad enough already, they just got worse. We now have people coming up with decisions all by themselves. No asking anyone about it, even in backroom meetings, or only to fake it and ignore their opinions on the matter. It looks bad, and it is. Talk about communication problems. Talk about power-hungry people. But let’s talk about cowards, too. The cowards that are bitching about what’s happening but won’t raise their voices on the lists because they’re afraid of looking bad if they disagree with the “big boys”. We are a free software project. Free as in freedom, free as in speech. If you’re not making use of this freedom, you’re just going to lose it; just like in the “real world”. Actually, you’ve lost some of this freedom already. If you’re not voicing your opinion, why do you have one in the first place?

Digi released a new beta release of the dgap drivers a couple of days ago, notably fixing the build issue (TTY flip buffer) with newer kernels. They now ship two versions of the driver, one suitable for 2.4 and 2.6 kernels up to and including 2.6.26, and one for kernels 2.6.27+. The appropriate version will be picked up automatically when the module is built, of course. APT source line, unchanged: deb http://debian.technologeek.org/ etch non-free The packages are still built for Etch; Sarge users should stay with 1.3.6 (unless running a newer kernel, but then a rebuild of the userspace tools is required). Feedback at the usual address.

Answer to anybody asking about the Lenny release.

I’ve just taken over the maintenance of mt-daapd and gave the package and code the thorough cleanup it so badly needed. I’ve fixed everything that was reported againt mt-daapd and a bit more. No miracles though, the code is still not great and there still hasn’t been an official upstream release in … years? It works for me as well as it did before, so hopefully I’ve fixed bugs and did not introduce new ones in the process. Now that’s up to you, mt-daapd users, to tell me :-) Go grab mt-daapd 0.9~r1696.dfsg-1 in experimental and enjoy.

Lazyweb-type post ahead :) I am looking for the UGA (Universal Graphics Adapter) specification. It is part of EFI 1.10, but was developed by Microsoft, so it’s not documented in the Intel spec. Instead, the Intel spec contains a Microsoft URL where the spec used to be available, but that URL doesn’t exist anymore and I can’t find the spec anywhere. So, if anybody out there has a copy of that spec, I’d very much like to get it. I am looking for the UGA IO Protocol spec, which may very well be the key to solving an annoying framebuffer issue I’m working on. Thanks!

It’s been on the TODO list for ages now, and Soeren finally tackled it: compositing support for gpomme. This is the only change in this release. Please report any issue with gpomme and compositing, as this code has only been tested on a limited number of configurations. For people not running a compositing manager (like myself), don’t worry, gpomme works just as before.

Aur lien JARNO defended his PhD this morning, and I’m just back from attending his defense. He did an incredible work designing and implementing a simulator for the MUSE instrument that will equip the VLT in 2012 (”first light”) and is being built now. People working in the field are very impressed by the work he achieved, and I must add that it’s even more impressive when you know all he did in Debian and various other projects at the same time. Wow. Congratulations Dr. JARNO!

As of 09:53am CEST today, I am officially available for hire starting mid-August, and looking for a job. I’m going to enjoy some time off in the nice, sunny weather we’ve got here these days and I’ll have some time again to try and add proper support for the Intel Macs to d-i. Not that bad after all.

pommed v1.20 is out, with two minor fixes:

• a segfault that could not trigger on any normal setup;
• use of the correct bus type to detect the Apple wireless keyboards.

Available on Alioth now, in unstable after the next mirror push. Also I have to block pommed >= 1.19 from entering testing because Linux 2.6.25 is not yet available in Lenny. I hope this will be fixed soon, in the meanwhile, grab the packages from unstable if you’re running testing with a 2.6.25 kernel.

Joey, I think your whole post only applies to HAL. Fact is, DBus lets you know through a dedicated signal that you’ve been disconnected from the DBus server; at that point, you cleanup the connection and try to reconnect. Works for me. Now, the fact that HAL (and/or libhal, it seems) provides no way of handling this situation cleanly is obviously a major bug. I’m not a great fan of all the desktop crap that’s being promoted and hyped lately, but I am positive about DBus. DBus provides the mechanisms to handle a DBus restart properly, HAL (and pretty much everything else) doesn’t use them, blame HAL, not DBus, for this one. As for the “DBus should never be restarted”… I have no idea why the DBus upstreams would think that, but that also wouldn’t be the first time distributions disagree with upstreams about what is good and what isn’t. The good news is, this is all free software and we can fix it without upstream’s blessing. If somebody out there really believes that it is OK for applications to crash/exit when DBus is restarted, then I don’t have the words. I won’t even mention the new behaviour of the DBus init script in Sid.

pommed v1.19 has landed, with improvements wrt CPU usage. This is especially true for gpomme, which won’t cause 10 wakeups/sec anymore. PowerTop fans, rejoice! I plan to fix wmpomme too, but as I’m probably the sole user, this can wait. pommed will also consume a bit less CPU, especially on machines without ambient light sensors. The new code in pommed makes use of the timerfd API introduced in Linux 2.6.25, hence you’ll need to run a 2.6.25 kernel or later; pommed will not operate properly on earlier kernels.

You maintain an application that uses DBus? Better yet, you are upstream for an application that uses DBus? Then, please: GET OFF YOUR ASS AND HANDLE DBus SERVER DISCONNECTION/RECONNECTION INSTEAD OF CRASHING kthxbye.